AWS Lambda

Compressing image while uploading it to S3 bucket can be easily done using lambda. While if your workload require lot of execution time or there is large amount of data to be processed, also workload where tweaking environment to suit workload, lambda can be less appropriate. Instead other computer service like EC2 and elastic beanstalk can be well suited for such task.

-AWS Lambda can be used for cron job with AWS EventBridge.
-When we use AWS Lambda use with API Gateway to only transport data to another service without any business logic.

I would recommend using AWS Lambda when you have one-off tasks that can be accomplished with a single function and do not require a persistent, constantly running compute resource. Some example use cases include file or image processing, data analytics (you might have DynamoDB stream updates to AWS Lambda for processing), in conjunction with API Gateway as a backend.
I would not recommend using AWS Lambda when your Lambda function has potentially long-running, asynchronous calls involved (e.g., calling out to a service hosted in another cloud platform). This can drive up execution time and, in turn, cost. While Lambda layers allow you to share code between Lambda functions, I would not recommend AWS Lambda for cases where there are high degrees of interdependence between the Lambdas. I think that Lambdas work better when considered isolated.

Well suited:
1. when we need to worry about time to market and we don’t have infra defined.

Not suited:
1. Not suited for Business Client transactions as its server are located out of Switzerland and hence country laws are different

Working with Web and mobile apps well suited for Lambda. It provides a clear support path and improvement. Also it helps to reduce cost and accelerate speed of reaction on changes.

A sess appropriate scenario would be when CIO push to implement new technology and services without clear understanding of the results and project needs.

The main area in my point of view is the automation reduction of costs. You can program and use Lambda to execute several tasks based in several types of events like logs, schedules, and output from other AWS tools. With the AWS API, you can do almost anything you want and your function will use only the needed resource (memory, cpu) so it is optimized.

AWS Lambda is a great way to deploy smaller-scale data synchronization jobs and other "housekeeping" routines that don't require preservation of state. We use it to build API gateway tools used by our larger applications (many of which are hosted on AWS EC2 instances) and it's a perfect fit.

If you have complicated workflows that run a long time, or require state to be saved between function calls, AWS Lambda is probably not the right choice for a serverless solution.

I know a lot of our developers use this personally to develop Alexa skills. The best use case for us is building simple rest API's with minimal effort and overhead. It is easy to use and scalable. You can also through a lot of load against it very quickly with little to no performance issues that I have seen. Also, it is very well suited in environments where developers have language freedoms.

AWS Lambda is best for short-lived applications/codes. Configure AWS Lambda to act based on the events that are produced on certain services. It works. We used it to move the RDS snapshot from WEST to EAST and EAST to WEST whenever the RDS automatic backups are done. It helps in other scenarios, like when application teams don't have a server or don't have a place to run a job on a regular basis. Then we can leverage this AWS Lambda to run the code against the database. As I mentioned, this is not suited for long-lived applications.

AWS Lambda is great for atomic micro services and being leveraged as a conduit for other Amazon services. It's great for a quick way to innovate other resources that you already have on the platform. It marries well with the ecosystem and allows for easy deployments and updates to the program based on the tools.

Anywhere you have an isolated responsibility of your code, AWS Lambdas are well suited for. If you have something that has to perform an intensive calculation - it makes sense to offload that to something like an AWS Lambda. Or something that needs to send data and integrate with another service, it can be a good place for that interface/job to live.

It can be possible to build a larger architecture using a series of AWS Lambdas, but it could become hard to maintain and be hard to understand very quickly.

Anywhere where you just pay for what you use. AWS Lambda is the best in those areas. As it is fast and scalable it can provide an excellent alternative for server backend making the whole application serverless. You just don't need the server running every time. Just run it when you need it.

AWS Lambda allows us to develop certain process without setting up a server. I would recommend AWS Lambda for a process that doesn't need to be real-time or needs to be always on.

Web requests are perfectly suited for Lambda, as are any events that can happen quickly. As Lambda supports more languages, such as Go and Node.JS, it becomes easy to ignore things like frameworks and just focus on a single function. Keep in mind that Lambda functions do not run constantly in the background, and only run when requested, so they are ideal for spikey workloads on-demand.

AWS Lambda is great for fast processing of data that can be placed on Amazon S3 storage. As long as the processing of the function is not longer than what AWS says a Lambda should run for and you do not do much processing, it is great. The cost can also be very good as long as you keep the price in the free area.

When to use:
Easily deploys functions/microservices without a server. Deploy code in several different languages (For instance: Your main app is Node.js but you want to launch a Python microservice? Simple!). Automate small tasks between different AWS services.

When not to use:
When you don't really have a microservice and you actually need a server! Or when you're not going to rely on other AWS services to make up for the lack of a server.

Eeveryone should be using Lambda functions for situations where code needs to be executed in response to something happening. Lambdas can be used in situations where you have lots of persistent data but in my opinion, they work better in ephemeral environments. Counting things with Lambdas is hard too, so you should probably avoid that.

Lambda is great when you have specific bite-sized functionality that you can split into multiple discrete functions. It is not well suited for large functions that do quite a bit. Sometimes you are able to split those tasks down into separate Lambda functions that effectively get chained together. For the cases where you can't, it's better to go with a standard backend.

Excellent for pretty much anything which is event driven. If you can consider a way of architecting your system to be micro-service oriented and event-driven then Lambda is a great fit.

On the other hand, if you need something where you are doing polling operations, particularly if its more frequent than once a minute, then there are probably better solutions for you.

The decision to use AWS Lambda is easiest if you've already committed to the AWS ecosystem of products. But AWS Lambda is also useful as a standalone product if you require any on-demand processing that only charges you when it is running. AWS Lambda is less appropriate if you need scripts with a persistent state.